GetX 缺陷

GetX 在 pub 上 在 Github 上都非常受欢迎
功能丰富
主题切换：比如深色模式切换；
多语言：可以通过配置 Map
搞定多语言；
弹窗提醒：包括了 SnackBar 和对话框；
路由：无需 Context 的路由跳转；
离线存储：不依赖原生的key-value 存储组件的离线存储 GetStorage ；
状态管理：快速接入的响应式状态管理；
工具类：例如表单验证工具，获取系统参数（平台类型，屏幕尺寸等）；
依赖注入容器：使用简单的 put 和 find 方法完成容器对象的注册和获取；
网络请求：可以使用 GetConnect 完成网络请求。

GetX 缺陷 GetX defect
国外的朋友怎么说
GetX 作者背景
Jonny Borges 目前在一家互联网公司
官网 //iris.finance/
公司规模不大Jonny Borges也是创始团队之一
应该是全栈大神

GetX的客观评价
之所以给这“客观”二字加上引号，是因为发现写这篇文章的作者自己出了个状态管理插件
要对标 GetX
因此至于是否真的客观大家自己感受
Flutter - Should I use GetX?
使用 GetX 的导航需要使用自定义的 MaterialApp 或 CupertinoApp
也就是需要使用 GetMeterialApp 或 GetCupertinoApp 包裹应用才能够在页面跳转时无需使用 BuildContext
对应用的侵入性比较强

SnackBar、对话框和导航的使用上不太合理
在这些实现的内部使用了静态的 context
这使得单元测试没法直接
而需要使用 widget testing配合完成

get_connect 插件集成了 REST API 请求和 GraphQL 客户端
这有点多余，一般的应用不会二者都用，这会导致插件部分功能多余（推荐网络请求还是用 Dio）

依赖注入和热重载问题
GetX 的依赖注入还不太成熟，如果依赖对象改变后（比如修改了依赖对象类型，增加了依赖对象），直接热重载会报错，这个时候往往需要 reload 才行
注释和文档比较糟糕
源码很多地方缺少注释，导致未来的维护可能会比较麻烦

而官方文档相对不完善
导致使用者需要自己摸索
代码组织性比较差：如果去阅读源码，会发现一个文件会有数百行，多个类、函数、变量都混在一个文件中

同时部分方法的命名也需要改进，比如路由的 Get.to ， Get.toNamed ， Get.offNamed
依赖注入的 Get.put
Get.lazyPut 等

这些方法名称如果不阅读文档很难推断出具体的功能
如果在方法和 Get 之间加一个模块名称会更好理解
如 Get.router.to
Get.dependencies.put
很多代码没有经过测试
由于 GetX 覆盖的功能实在太多，很难做到每个功能特性都做完善的测试，这会使得其中可能存在隐藏的 Bug

使用 GetX 的建议
建议只使用必要的模块
比如 GetX 的状态管理、响应式编程和依赖注入，而像导航和绑定这类的功能要慎用

虽然有上述的问题，但 GetX 不失为一个很强大的插件
只是在实际应用中需要小心
对于全盘接收 GetX 的用法要注意其风险

总结
从国外这位作者的评价和本人的实际体会来看，这位作者说得还是相对客观的
随着 Flutter 生态的日益完善，实际在 Flutter 的开发中有很多 GetX 功能特性的替代者
因此建议来说不要为了简化开发而全盘使用，这样一旦GetX出现问题或者升级跟不上可能导致整个应用的维护升级都面临巨大的工作量